The presented invention relates generally to the use of test logic hardware to prove out integrated circuit design and, more particularly, to a method for automatic validation of integrated circuit test logic.
The soundness of the logic design of an integrated circuit (IC) device or part must be tested prior to actually manufacturing the hardware. This is especially true of extremely complicated and exceedingly dense ICs, such as complex central processor units (CPUs) and microprocessors, which may have close to a billon transistors. Now in order to be able to observe the minute details of the inner workings of such extremely complex devices after manufacture, appropriate test circuitry, in addition to the other functional pieces of logic hardware, needs to be designed inside of the chip during the design phase of the chip.
Unlike major functional blocks of the chip, such as an integer block or a floating point block whose die location can be precisely determined, however, the entire test hardware of the chip is composed of a great number of serially connected test components called scan latches that are scattered through the chip to ensure that observability and controllability are provided for each and every portion of the chip. FIG. 1 illustrates a sample scan latch composed of a test latch portion electrically coupled to a functional portion, as indicated by the dashed lines. It can be seen that the test latch portion is provided with test data input, TDI, which can be provided locally to the scan latch, and controlled by various test signals, such as SHIFT, NSHIFT, LOAD (WRITE), and UPDATE (READ), to capture functional data OUT and output test data output (TDO), which is in turn provided to the functional latch portion. The functional latch portion is controlled by a qualified clock signal, CKQ, which in turn is controlled by an appropriate test signal (not shown here) to ensure that the output signal OUT of the scan latch is controlled by TDO (via the WRITE test signal) when the IC chip is in the test mode and by the IN data input in the normal operating mode.
In the normal operating mode, WRITE test signal is OFF while CKQ fires. If the WRITE test signal does not fire, the functional and test latch portions perform independently. The normal data, IN, is passed through to the output signal OUT in the normal operating mode. Conversely, in the test operating mode, firing the WRITE test signal controls the output signal OUT. The UPDATE (READ) status signal transitions to read in the captured data OUT and the SHIFT and NSHIFT signals shift TDI into the scan latch and also transfer captured data OUT through the scan latch. The WRITE test signal fires, thereby transferring the local test data out TDO to the functional latch.
The test signals, such as SHIFT, NSHIFT, LOAD (WRITE), and UPDATE (READ), that are used to control the operation of the scan latches are produced from a single test control block, called a test access port (TAP), which can control operation of the entire test hardware of the chip. Often, however, the overall control of the test hardware scan latches is broken down between smaller test control blocks, called mini test access ports (MTAPs), that are each centrally controlled by a single, and much simpler, TAP. Each MTAP provides data and test signals to a series of scan chains or scan paths that are connected in parallel. Each MTAP, and its corresponding scan chains, may typically be dedicated to testing a particular functionality of the chip. To this end, it is not uncommon to have a particular MTAP and set of scan chains dedicated to a particular functional block, such as a floating point block, for instance. There is no requirement, however, of a one-to-one correspondence between MTAP/scan chains and functional block. Thus, each block, or sub-block, or functional piece of the IC chip may have two or more MTAP/associated scan chains combinations.
An illustration of such a distributed test architecture is shown in FIG. 2. As previously mentioned, the scan latches that make up the test hardware of the chip are organized as serially connected test components. Related scan latches that are used for testing a particular functional piece of the IC device, such as a particular type of block or a functional sub-block of a block, are serially arranged in a particular scan path; multiple scan paths of a particular MTAP are connected in parallel to one another. The TAP is provided with various input test signals, shown here as TRST (test reset), TCK (test clock), TMS (test mode select), TDI (global), and TDO (global). The global data and test signal are provided to each of the MTAPs by the TAP. Each MTAP, in turn, provides its corresponding scan paths with local normal and test input data and test signals appropriate to the particular block, sub-block, or functional bit of the IC chip they are serving. The local test results are provided by the scan paths back to their particular MTAP, which in turn provides the test data back to the TAP over a global connection. It is noted here that global as used herein refers to signal communications between the TAP and the MTAPs, typically across functional blocks of the IC chip. Typically communications between MTAPs and their scan paths will occur within a functional block of the IC chip and thus be local in nature. FIG. 3 illustrates the serial connection of two scan latches in a simple scan chain; of course, an IC chip will have thousands or more such serially connected latches in a scan chain. In a scan chain or scan path, normal input data NDI and test input data TDI, as well as test signals, such as SHIFT, NSHIFT, LOAD (WRITE), and UPDATE (READ), will be provided to the initial scan latch. Depending upon whether the IC is in the normal operating mode or the test operating mode, the initial scan latch will pass along the appropriate type of data to the next scan latch in the scan chain via logic circuitry by which contiguous scan latches in the chain can communicate.
It is current practice in the art for a chip design team to spent a great amount of time adding a few extra pieces of hardware to obtain specific performance benefits and/or to port or re-layout an existing design to a new manufacturing process in order to improve performance. Although this means that most blocks are virtually untouched in terms of any change in functionality, this is not true for the test hardware. Any new hardware that is added will need to have test circuitry in the form of scan latches built inside it to be able to observe and control certain critical functional signals during the debug and characterization phase of a chip after it has been manufactured. These scan latches will then need to be serially connected to each other and also to the global scan chains described above. The appropriate test signals will need to be routed over to the new piece of test hardware from the test control blocks (TAP and MTAPS). Any porting of an existing design to a new manufacturing process causes metal routes to be relocated and replaced with faster metal layers, thereby causing the occasional opens, shorts and faulty connections in global test signals and in functional signals. And for purely functional signals, possible problems are found during functional verification of the chip, as well as or in addition to, during static or dynamic timing analysis of the chip. But the validation of test signals and test hardware requires a whole new effort because the test hardware is almost always very simplistically modeled in global functional verification runs that tend to focus on strictly design (not test) issues and is also almost always generally ignored in global static/dynamic timing runs. Since the test control blocks (TAP and MTAP) are almost untouched, except for porting the design to a new manufacturing process, etc., the validation effort on test hardware should focus heavily on having the correct connectivity of the test signals to the scan latches themselves. Also, electrical quality of the scan latches, ascertained by checking the strength of the feedback inverter to prevent flipping the latch on a noise event at the input, checking the output drive strength of one scan latch to see that it is sufficient to toggle the subsequent scan latch, etc., and global routings for the test signals should also be verified so that the target scan frequency (the rate of transfer of captured data and/or test data through the scan latches) can be obtained.
Now while the importance of test hardware cannot be over-emphasized for today""s highly integrated chip devices, its significance is often undermined because of the competitive benefits believed to accrue with other, real performance measures like clock frequency, cache size, accurate branch prediction techniques. A poorly designed and validated test hardware approach, however, can make debugging designs in real silicon a nightmare, often greatly adding to the amount of time required to get a product to market.
There are several disadvantages associated with traditional approaches to validating test hardware. First, traditional approaches may rely upon the readiness or xe2x80x9ccleanlinessxe2x80x9d of an entire block or a large piece of a block, when the test hardware inside the block usually accounts for only a small portion of the total silicon xe2x80x9creal estatexe2x80x9d of the block; test hardware may often account for less than five percent of the total real-estate of a block, for instance. Second, block databases may be required and represent a cumbersome requirement that greatly adds to the overhead associated with testing. Third, a lot of the scan latches of the test circuitry are themselves disjointed in the sense that the functional and test portions of a scan latch may often be physically separate logic represented by different artwork describing layout of the respective circuitries. This is especially the case in logic related to dynamic circuits in which the functional piece and the test piece of the scan latch may be separate leaf cells but test signals will still reach the functional leaf cell. Since the functional piece is properly not considered part of the test portion of the scan latch, the test ports of the functional piece are not checked to make sure that they are connected to the correct global test signals. For instance, in the case of a dynamic bus which has multiple functional pieces of logic driving the bus and a single scan latch to control it, it is very difficult to test these functional pieces which receive their own, often distinct, test signals. Fourth, the functional simulator used to verify test signals often runs into difficulty in understanding some special circuits, such as sense amplifier circuits in caches, phase lock loops (PLL), etc. While these circuits have nothing to do with the test logic per se, a considerable amount of time must be spent in describing them to the functional simulator so that the simulation can be performed.
The present invention presents a method for automatic validation during BDL extraction of test hardware of an integrated circuit device. A test hardware portion of connectivity of the integrated circuit device is extracted; electrical and functional validation of the scan latches, test control blocks and test signals of the test hardware is performed during extraction. Following extraction and validation of the test hardware portion, the test hardware portion may be represented in a block description language. Any logged errors, such as test signal connectivity errors, scan latch inter-connectivity errors, etc., that are identified during the extraction and validation process may be used by IC designers to improve the test hardware portion.
During the first extraction procedure, the connectivity of test signals, which reside at a number of test signal output ports of a test control block of the test hardware portion having serially-connected scan latch instances, to the serially-connected scan latch instances is determined. Any test signal connectivity errors identified during the first extraction procedure are generated and logged for future reference. During a second extraction procedure, the inter-connectivity of the scan latch instances is validated. Any scan latch inter-connectivity errors identified during this validation pass, are generated and logged for future reference.
This procedure may be repeated for any test control block (TAP, MTAPs) of the test hardware portion. The extracted and validated test hardware portion of the connectivity of the test hardware is in a block description language. Any results recording during the extraction and validation process can be used by the designers to improve the test hardware. The methodology of the present invention may be implemented as executable computer program instructions of a computer readable medium executed by a processing system.